\documentclass[12pt]{article}
\usepackage{setspace}
\usepackage{url}
\usepackage{graphicx}
\usepackage[left=1.25in,top=1.0in,right=1.25in]{geometry}
\doublespace

\author{Aaron A. Lovato \and Charlie Moore}
\title{FReeConf: Implementing RBAC in FreeRADIUS}

\begin{document}
\maketitle

\begin{abstract}
We implemented a system that allows an administrator to keep track of an RBAC
access control mechanism on multiple servers.  There is a commercial level
solution to this, but our project's scope wasn't to invent something completely
new; it was to implement concepts that we learned in class.  We implemented a
form of ERBAC and allow centralized administration of multiple servers.
\end{abstract}

\section{Introduction}
RBAC (role-based access control) models are well-recognized for their advantages
in the field of large-scale authorization management~\cite{nistrbac}. The concept
of roles is particularly well-suited to an environment that requires a standard,
enterprise-wide access control and authorization environment.  This is because many
entities (e.g., corporations) that would desire such a solution have a
organizational structure that can be represented by roles. Additionally, a large 
number of such organizations have begun to utilize roles at the enterprise
level~\cite{observations}; thus, enterprise-level solutions to implement RBAC
would be of benefit to such organizations. 

There is a commercial solution available today; as this area of research is a
hot topic and is being funded by industry giants such as IBM.  The authors of
the papers that we've read in this area implemented a program called SAM
(security administration manager) that they reference throughout their papers on
E-ARBAC.  Other vendors have started to implement RBAC in their security
management and other systems~\cite{nistrbac}. We feel that a lack of a uniform
access control and authorization system along with the need for each product to
implement its own access control thus required is one drawback for application
developers or system designers wishing to utilize RBAC. Furthermore, because a
typical enterprise user requires access to a wide variety of applications on
different platforms, the application-specific nature of many current role
concepts causes unnecessary overhead~\cite{observations}. The access rights on
multiple systems must be administered separately because no common RBAC support
is implemented~\cite{observations}. This project attempts to provide a uniform
system with such support by implementing RBAC using FreeRADIUS, an
implementation of RADIUS, well-known authentication, authorization, and
accounting protocol~\cite{freeradwiki}.

\section{Background}
\subsection{ERBAC}
Since the introduction of RBAC, a substantial amount of research has been done
on the subject of enterprise-level role-based access control (ERBAC). As with
level 2a of the RBAC model, a general role hierarchy is supported in
ERBAC~\cite{erbac}. This role hierarchy supports the creation of Enterprise
Roles: roles that span over more than one target system and consist of
permissions in multiple systems~\cite{erbac}. The size of these roles alone
increases administration overhead greatly, especially since the Enterprise Roles
span systems with greatly varied sets of permissions.

It must be noted that, in order to manage the administration of such a large
system, the concept of Administrative Enterprise Role-Based Access Control
(A-ERBAC) has been introduced~\cite{erbac}. This concept includes the definition of a
hierarchical set of scopes~\cite{erbac} within which administrative levels are
defined. The purpose of these administrative levels is to make management of
administrative objects realistic. Of particular relevance to our work is the
fact that administration of the role-permission assignments occurs at the
central administrator level~\cite{erbac}. Thus an administrator at this level
must be allowed to manage these varied sets of objects and
actions. Interestingly enough, lower level administrators (e.g., local and help
desk administrators) do not have the ability to modify the role-permission
assignments~\cite{erbac}. However, such administrators have varied permissions,
including view and edit on certain types of objects~\cite{erbac}.

\subsection{RADIUS}
RADIUS is a protocol for remote authentication, authorization, and
accounting~\cite{freeradwiki}. It is well suited for networks that need a
centralized authentication service~\cite{freeradwiki}, which makes it an ideal
fit for this project. RADIUS, as a protocol rather than a specific
implementation, provides a great deal of flexibility in the implementation of
its features. However, the standardization provided by the protocol is very
useful in our implementation of this project. In particular, the specified
behavior of the Access-Request is depended on by our implementation. 

\subsubsection{Access-Request}
A client sends an Access-Request packet to a RADIUS server to authenticate a
user as well as determine what access that users is to be given~\cite{radiusrfc}.
Upon receipt of the Access-Request, the server will determine if all conditions
(e.g., password) from its database of users are met~\cite{radiusrfc}. If any
conditions are not met, the server replies with an Access-Reject
packet~\cite{radiusrfc} indicating that the user was not authenticated and should
not be given any permissions. If all conditions are met, the server may reply
with an Access-Accept packet that contains all configuration values for the
user~\cite{radiusrfc}. Note that RADIUS servers do implement other behaviors;
however, these behaviors are not used in the implementation of this project.

\subsection{FreeRADIUS}
FreeRADIUS is the "most widely deployed RADIUS server in the
world"~\cite{freerad}. It is currently supported by the FreeRADIUS project, an
open-source software development project. FreeRADIUS supports a very large
number of authentication methods, ranging from simple clear-text passwords to
more complicated methods such as Kerberos\cite{freeradwiki}. However,
managing the large number of configuration files associated with this
flexibility is a daunting task. Furthermore, since adding and managing users
requires manual editing of these files, configuring in a standard access control
mechanism such as RBAC is nearly impossible by hand. Another obstacle to the
implementation of RBAC is the fact that FreeRADIUS has no constructs that can be
used to represent roles.

Of the aforementioned configuration files, we identified 2 types that must be
managed in order to implement RBAC in FreeRADIUS: the users file and the
dictionary file.

\subsubsection{Users File}
The users file is essentially the database of users mentioned in section 2.2.1
above. Each user is assigned some requirements for authentication and a list of
configuration values to be returned to a client upon successful authentication.
Each configuration value is of the form "name = value."

\subsubsection{Dictionary Files}
Every configuration name must have a corresponding entry in the FreeRADIUS
dictionary of attributes. The reason for this dictionary is so that clients can
correctly decode configuration values returned from the server. Many of these
attributes are defined in the RADIUS RFCs because clients need some standard way
to decode the responses. However, in order to support custom attributes, RADIUS
allows Vendor-Specific attributes to be defined\cite{radiusrfc}. We utilize this
flexibility to allow arbitrary permissions to be mapped into the standard
configuration value format.

\section{Related Work}
SAM Jupiter, a commercial enterprise security software, has been utilized to
implement A-ERBAC\cite{erbac}. We recognize that this software provides a much
more complete solution to the problem we have stated; however, the commercial
nature of this software prevented us from obtaining a copy for specific
comparison. Furthermore, by going through the process of designing our own
implementation, we were able to concretely apply our knowledge of access control
systems obtained in this class as well as greatly expand it. 

\section{Approach}
Since the assignment was an implementation assignment (see appendix A), we
developed an application called FReeConf that implemented RBAC in
FreeRADIUS. There are some configuration applications for FreeRADIUS, but they
are very few in number and none of the ones we discovered allowed the user to
implement RBAC, so this approach holds promise for allowing RBAC to be
consistently used across an enterprise network. The general idea behind this
application is to allow an administrator of a FreeRADIUS server to create user
configuration files that reflect a general hierarchical RBAC system (level 2a in
the NIST standard~\cite{nistrbac}) and manage the state of these files on a
FreeRADIUS server. To accomplish this end, the application outputs the specific
FreeRADIUS configuration files necessary to manage users and permissions on the
server. The application has the ability to push the configuration files to the
server as well as gather the files currently being used by the server and
verifying them against the "correct" files. This verification is done using the
SHA-256 hashing algorithm to ensure the local files and the remote files match.

We designed our application roughly following the Model-View-Controller
architectural design pattern.  The back-end API was designed first, and is
essentially our model, the Server class that's described later is the
controller, and the GUI widgets are our views.  Java Swing GUI widgets enforce
this sort of design style as every widget has a model (which can be mapped to
our underlying model) part and a view part.

\begin{figure}[h]
  \centering
  \includegraphics[height=4in]{architecture}
  \caption{Architecture Diagram}
  \label{architecture}
\end{figure}

Figure~\ref{architecture} describes our architecture at a high level.  Our
program fits in between the central administrator and the RADIUS server.  The
central administrator is modeled after the eponymous concept
in~\cite[p. 7]{erbac}.  The permissions that the central administrator needs are
enumerated in Figure~\ref{perms}.  This administrator must do the role creation
and permission assignment and then our software will translate that into a form
that RADIUS can understand and make its access judgment upon.  FReeConf creates
the RADIUS configuration from the central administrator's input and then writes
it to the RADIUS server.  Then the RADIUS server serves its clients as usual
based on the created configuration.

\begin{figure}[h]
  \centering
  \includegraphics[height=1.5in]{admin_perms}
  \caption{Central Administrator Privileges~\cite{erbac}}
  \label{perms}
\end{figure}

\subsection{Back-end Design}
There are 4 main classes used to represent the configuration of the FreeRADIUS
server: User, Permission, Role, and Server.  These are natural objects that we
generated from a rational look at the design requirements.  The first three map
onto distinct RBAC concepts while the last is our controller object.  What we're
really modeling in our program is RBAC for a \emph{number} of Servers.  Since
every Server must know its own users and roles, we must keep track of this in a
separate object.

\subsubsection{User}
The primary purpose of the User class is to contain all about a user that the
FreeRADIUS server needs to know, which are essentially  the requirements
mentioned in~\cite{radiusrfc}. In our implementation, a User is simply a user
name and a password because we only support PAP authentication at the moment. 
Using this class makes the back-end of the application easy to
extend to support more complicated authentication protocols that need additional
requirements and/or configuration values in the FreeRADIUS configuration.


\subsubsection{Permission}
A Permission represents an arbitrary permission assigned to a User. We represent
the permissions by assigning the user a configuration value in the users
database. This class is a container class for the name and value of such
configuration values. We map the object of a Permission onto the name of an
entry in the users file and the action onto the value of the entry. The
primary purpose of the Permission class in the system is to clearly establish
the mapping of roles onto permission defined for RBAC policies~\cite{nistrbac}.

\subsubsection{Role}
The Role class establishes and maintains the user assignments and permission
assignments that are central to RBAC~\cite{nistrbac}. Note that these assignments
are on a Role-by-Role basis and each Role does not interact with other Roles
outside of establishing a hierarchy; thus, the many-to-many relationship between
roles and users as well as roles and permissions~\cite{nistrbac} is not
restricted.  In this conceptualization, our Role object draws a strong
parallel the Enterprise Role concept.~\cite{erbac}

Our concrete Role implementation is a graph in which each node has a list to its
predecessors (parents) and successors (sub-roles).  An actual graph
implementation is required to implement the general hierarchy form of RBAC.
While our specific application implements level 2a RBAC, we left the
implementation of permission inheritance to a higher level object (Server in our
case). This was done to allow extension to a more complicated level of RBAC
(e.g.  constrained RBAC) without requiring modification to the underlying Role
class.


\subsubsection{Server}
The Server class represents a controller object for the GUI widgets. It keeps
track of all the roles and users, and manages the user assignments and
permission assignments. It is also responsible for creating the mapping from the RBAC
configuration to the FreeRADIUS configuration files. Additionally, it provides
convenient methods for manipulating its data, which are used by the GUI to
manage the configuration.  In order to keep state between multiple runs of
FReeConf, the Server is responsible for serializing its state to disk and
inflating that serialized data back into Java objects.  We achieve this
serialization with a custom XML format that allows us to capture all of the
hierarchy information.

The mappings the server maintains are rather straightforward and intuitive from
the definition of user assignments and permission assignments in
\cite{nistrbac}. Because Roles have multiple parents and children, per the
requirements for both level 2a RBAC \cite{nistrbac} and for representing
Enterprise Roles \cite{erbac}, the server is responsible for propagating
permissions from parent roles. We accomplish this by utilizing the parent list
in each node to recursively traverse the list of parents and building up the
list of all permissions. Thus each role inherits the permissions of all its
ancestors, fulfilling the general hierarchy requirement for an Enterprise
Role\cite{erbac}.

In order to actually manage the configuration on the FreeRADIUS server, we need
some way to copy the locally generated configuration files to the FreeRADIUS
server. For the sake of simplicity, we use the \textit{scp} command to place the
configuration files at a specified location on the FreeRADIUS server. Similarly,
we implemented the ability to copy the files currently on the FreeRADIUS server
back to the host running FReeConf in order to verify the integrity of the files.
The SHA-256 checksum is then calculated and compared to the checksum of the
locally generated configuration files.

\subsection{GUI Design}
We took the time to design the GUI correctly to ensure that given enough time
with future work, it would be a viable interface.  GUI work isn't trivial, and
we did a lot of it.  We required an intuitive GUI to manage the roles, users,
and permissions.  Java Swing was used as it provides native-looking widgets and
we had committed to using Java as the language for our project.  Roles, users,
and permissions are all straightforward to model, so the API is intuitive and
easy to show correct.

One big departure in our GUI is the fact that we show the role hierarchy as an
inverted tree instead of the traditional way with ``more'' permission at the
top.  We believe that this way makes more conceptual sense, because as you go
``down'' our tree, you can see how the permissions accumulate.  The problem with
viewing general role hierarchies as trees is that the underlying data structure
is really a graph.  As shown in Figure~\ref{diamond}, there can be an arbitrary
number of parents and children, leading to ``diamond'' shapes that can only be
shown in tree form as duplicated subtrees.  With the inverted sense (more
privilege at the bottom), this means the Dictator role from Figure~\ref{diamond}
will appear twice as a leaf if you duplicate this example in our program.

\begin{figure}
  \centering
  \caption{A role hierarchy with a diamond.}
  \includegraphics[height=2.9in]{diamond.png}
  \label{diamond}
\end{figure}

\section{Discussion}
Because FReeConf allows the FreeRADIUS administrator to manage both user
assignments and permission assignments, as well as user and role creation, it
provides the functionality required by a central administrator in ERBAC.
While one could conceivably use FreeRADIUS to implement the hierarchy of scopes
detailed by \cite{erbac} using proxy FreeRADIUS servers, our approach only
supports a single level of administration. In order to extend this project to
support multiple levels of administration, we would need to formalize the
administrative permissions for each level and enforce restrictions on the user's
ability to view/edit the configuration values.

Also notably lacking from our implementation is any sort of administrative RBAC.
This is due to the fact that FreeRADIUS requires clients to be known and a
shared secret to be set up. Thus, in order to authenticate the administrative
user, FReeConf would have to set up the user's host as a client on the
FreeRADIUS server. We feel that this functionality could be implemented if
either FReeConf were extended to manage the whole FreeRADIUS configuration
(e.g., manage clients) or if the functionality we implemented were integrated
with a more complete configuration management application. 

Sessions are another part of RBAC that we did not successfully implement. We
originally planned to use groups in FreeRADIUS to allow users to authenticate
for different roles; however, this approach is not feasible. After researching
various other features in FreeRADIUS, we have come to the conclusion that
implementing RBAC sessions is not possible using FreeRADIUS.

\section{Conclusions}
In conclusion, we implemented an application to allow a FreeRADIUS administrator
to configure a server using RBAC. Our implementation supports level 2a RBAC as
well as features of Enterprise Roles, which greatly opens up extension
potential. We discovered that several features of RBAC are not possible to
implement using FreeRADIUS, although the majority of level 2a RBAC can be
successfully implemented. 

We were able to concretely apply knowledge we obtained in class in order to
produce a functioning and functional RBAC manager.  There is already commercial
software that deals with this topic, but the point of the project was to learn
ourselves how exactly to go about designing and implementing a system like
this.

\appendix
\section{Appendix}
\subsection{Proposal}
FreeRADIUS is an open source implementation of the RADIUS protocol for unix-like
systems.  RADIUS itself is ``a protocol for remote user Authorization, Authentication
and Accounting. Its primary use is for Internet Service Providers, though it may
as well be used on any network that needs a centralised authentication and/or
accounting service for its workstations.''~\cite{freeradiuswiki}

Role-Based Access Control comes in many forms.  We're going to focus on the
general hierarchical (level 2a) RBAC for this project.  According to Sandhu et
al., ``With RBAC, access decisions are based on the roles individual users have
as part of an enterprise.''~\cite{nistrbac} As such, using a centralized
authentication and authorization system such as FreeRADIUS would be an ideal way
to implement RBAC across an enterprise.  The tool we're proposing to build would
allow the administrator to define these roles along with specifying subjects and
permissions.  The system will then be able to manage access control by the
mapping of users to roles, simplifying administration.

\subsection{Problem}
The Role-Based Access Control method fits naturally into the capabilities of a
centralized authorization server like FreeRADIUS, yet there is currently no way
to easily configure RBAC into it.  In fact, there's currently no GUI to
configure FreeRADIUS at all.\footnote{\url{http://freeradius.org/related/}} This
is a problem because without a standard way to produce and manage the
configuration files, servers can be easily misconfigured by hand.  The
configuration files we're dealing with are huge: there are hundreds of options
that the administrator must take into consideration in the context of all the
others to ensure a secure system.  Even if RBAC is being configured into
FreeRADIUS manually, the roles aren't evident in the configuration structure;
they're an implicit construct. RBAC configuration tasks, e.g. giving a user a
role, requires external tracking, which doesn't exist at the moment.

\subsection{Approach}
We propose to build a Java application to configure Role-Based Access Control
for FreeRADIUS.  We will need to create a way to keep track of users, groups,
roles, and permissions and the various connections between them.  Some examples
of the general types of operations are as follows: giving a user a role, adding
a user to a group, assigning permissions to roles, etc.

We will implement a way to push the generated configuration files to FreeRADIUS
servers.  This will allow a system administrator to manage multiple FreeRADIUS
servers at a time from the same software and keep all of his managed
configurations current.  We will also have a way to verify that the
configuration files haven't been tampered with.

FreeRADIUS supports a wealth of authentication methods.  We will support several
of the simple authentication methods to start.  If time permits, we will add
more.  We will implement group support, which will allow us to support sessions.
This will satisfy the requirement that a user can activate multiple roles
simultaneously.

\subsection{Expected Results}
We expect to have a user-friendly GUI that will allow us to configure FreeRADIUS
with RBAC capabilities. This will allow system administrators to easily generate
and manage FreeRADIUS configuration files at a much higher level of abstraction
than the text file configuration system currently allows. Implementing RBAC
through FreeRADIUS should allow applications and systems to be configured to use
a centralized authentication and authorization system for access control rather
than needing a individual configuration and management.

\nocite{*}
\bibliographystyle{plain}
\bibliography{refs}


\end{document}
